End to end (e2e) media in a communication network can be protected using a ticket based key management solution, as described in PCT/SE2007/050927, and illustrated in FIG. 1 herein. In the communication network shown, User A 1 can communicate with User B 2 and also a Key Management Server (KMS) 3. Similarly, User B 2 can communicate with User A 1 and the KMS 3. When User A 1 initiates a call to User B 2, User A 1 first sends 51 to the KMS 3 a request for a key to base security on (the security is used to secure the media or other type of communication between User A 1 and User B 2) and a ticket for User B 2. The KMS 3 sends a response S2 to User A that includes a key and a ticket for User B 2. The ticket either contains the key, or it contains a reference to the key which is stored in the KMS. User A then sends S3 a message to User B 2 to initiate a communication. This message includes the ticket that User A previously received from the KMS 3. When User B 2 receives the ticket from User A 1, User B 2 sends S4 the ticket to the KMS 3 with a request that the KMS shall resolve (i.e. return the key associated with) the ticket. The KMS 3 sends a response S5 to User B that includes the key. Once User B 2 has the key, it can receive secured data from, and transmit data to, User A. The ticket may contain more information than the key itself, such as key life-time, intended receiver, usage rules, etc. Another example of a ticket based scheme is the well-known and widely deployed Kerberos scheme.
A problem with such a system occurs when forking is required. Forking occurs when, for example, an INVITE message is directed to several devices (simultaneously or sequentially) and the first one to answer picks up the call. Forking is used to reach a person who has several devices and would like to be able to pick up a call on anyone of them. Another situation in which forking may be used is in a manager and secretary environment. The call is first directed to the secretary, and if the secretary doesn't answer, the manager may pick up the call (or vice versa). If this situation is solved by the use of forking, it means that both the manager's and the secretary's phone will ring simultaneously or first the secretary's and then the manager's phone rings and the first one to pick up the phone picks up the call. WO 2005/078988 is concerned with key management between devices belonging to different network or network domains, but does not consider the problem that arises where a user has several different devices, any one of which could respond to an INVITE.
The ticket based system doesn't provide an efficient and secure solution to the forking problem. User A 1 cannot in advance know for certain which device will pick up a call, and so it must request a ticket associated with a key that can be used by any device in a group of devices to which the call is forked. This would then mean that either all of those devices in the group of devices could send the ticket to the KMS 3 and receive the key, or the KMS 3 could implement a policy that it only returns a key to one device, for example the device that first requests the key. The first option is inappropriate in many scenarios. In particular, where accountability is needed, there is a risk that the devices can get infected by malicious software, or several physical persons may share the same subscription. The second option requires the KMS 3 to maintain state, which is undesirable from the perspective of reliability, storage space and Denial of Service (DoS). The KMS 3 would either have to hold information about all tickets that have been generated and are valid but which have not been resolved, or it would have to keep a record for the remaining life-times of all tickets submitted for resolution. Setting an appropriate life-time is a difficult issue; it should be as short as possible to minimize the storage needed by the KMS 3, but it should also be long enough to cover circumstances where a long ticket life is required, such as if a user wishes to resolve tickets for messages left on the user's answering machine after coming back from a four-week vacation.
For security reasons it is essential that all the devices that may be included in the forking should use different keys. For example, the secretary should not in general have access to the key used by the manager. A proposed IETF solution (Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) draft-ietf-avt-dtls-srtp-06.txt) relies on negotiating the key in the media plane. Of course, this requires that the call has been established and that the negotiation traffic can and is allowed to be carried in the media plane. If several of the devices that the forking included negotiate a key, their keys will be different. However, this solution is not easily adaptable to a ticket based key management system. Proposed 3GPP solutions (such as TR 33.828v0.8.0 clause 6.4.5) include letting the terminating device define the key, or use a combination of a key generated on the initiating side and a key generated by the terminating device. The proposed solution of having the terminating device generate the key suffers from the problem that either the sender and receiver has to have established shared keying material already, or an existing public key infrastructure needs to be in place to secure the transport of key information from the terminating to the initiating device.